home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000011_icon-group-sender _Mon Aug 22 12:08:36 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 22 Aug 1994 13:04:18 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: Mon, 22 Aug 94 12:08:36 EDT
  4. From: dburton@salzo.cary.nc.us (David Burton)
  5. Message-Id: <21VgRc6w165w@salzo.Cary.NC.US>
  6. Organization: SalzoBoard BBS * 919-481-3787
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <330a3u$3vq@shum.cc.huji.ac.il>
  9. Subject: Re: Simple syntax? A definition?
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. mslamm@pluto.cc.huji.ac.il (Zvi Lamm) writes:
  13.  
  14. > It appears to me that what counts is simplicity.
  15.  
  16. Agreed.
  17.  
  18. >                                             A simple syntax would be
  19. > one that can easaly be built (NOT parsed) by programs
  20.                                ^^^^^^^^^^^^
  21. No.  Any language is easily emitted by programs.  A simple syntax must
  22. also be easily parsed.
  23.  
  24. >                                            It would also be easy for
  25. > humans (that's us!) to learn and use.
  26.  
  27. Right.  And that means excluding things that add to the learning curve
  28. but do nothing for the expressive power of the language: like precedence,
  29. and (less importantly) multiple, independent global name spaces.
  30.  
  31. The language should also be easy to read; that is, easy for a human to
  32. parse, as well as for a machine.
  33.  
  34. > Does anyone have suggestions on how to define this in a more mathematical
  35. > or precise way?
  36.  
  37. For readability, it should be top-down recursive-descent (LL) parsable.
  38.  
  39. >   I thought about YACC clauses/sentence. But I am not sure
  40. > it's enough because the YACC approach narrows you down to LALR.
  41.  
  42. The problem is not that YACC parsability limits what you can parse, but,
  43. rather, that it does not limit it ENOUGH!  A simple language is not just
  44. LR or LALR parsable, it is also LL parsable.  Otherwise, the reader of
  45. the language has to "look ahead" and read language tokens without/before
  46. knowing what is being specified.
  47.  
  48. Out of consideration for the *humans* that have to read and write the
  49. languages, no language should be designed that is not LL (top-down)
  50. parsable.
  51.  
  52. -Dave Burton  <dburton@salzo.cary.nc.us>
  53. For my PGP public key, finger dburton@cybernetics.net
  54.